As with any software system, the Mac OS works fine just as long as everybody plays by the rules. For general Toolbox operations, these rules are fairly easy to understand. However, traditional Mac OS device drivers (DRVRs), by their very nature, are complicated programs, and the rules that govern their behavior are harder to understand.
This Technote discusses one of the dangers of writing a traditional Mac OS device driver, namely, the possibility of deadlock when calling another dev Ãice driver synchronously from a device driver. It demonstrates several ways this deadlock can occur, and then goes on to describe how to avoid the possibility of deadlock.
The Note is intended for developers writing traditional Mac OS device drivers, especially drivers which call other device drivers, and for those with a morbid curiousity about the internals of the traditional Mac OS.
Two Rules That Govern Device Drivers
There are two important rules about writing traditional Macintosh device drivers.
Rule #1
If your device driver can be called asynchronously and you call another device driver, you must call it asynchronously.
If you donÕt follow Rule #1, you run the risk of deadlocking the syst Sem, with catastrophic results for the user.
Note: According to Andrew S. Tanenbaum, in Modern Operating Systems, ÒA set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause.Ó For example, if I canÕt finish this Technote until I have a reliable version of your disk driver, and you canÕt make your disk driver reliable until you have read the finished Technote, we are deadlocked. Humans are good at avoiding and recovering from deadlocks, but computers are not.
Rule #2
If your device driver can be called asynchronously, always operate as if you are being called asynchronously.
In other words, you should not test to see whether this operation is synchronous or asynchronous, and do different things in each case.
If you donÕt follow Rule #2, the system might trick you into doing illegal things at interrupt time, such as breaking Rule #1.
Proof by Example
This section describes two examples of how breaking the rules will cause the system to deadlock. Both examples rely on the following scenario:
You have written a block device driver that fetches disk blocks over the network using the ÒclassicÓ AppleTalk device drivers. When you use the Finder to copy files to the disk image, the system will sometimes deadlock in a routine called vSyncWait. This is much more common when runnin
g Open Transport than when running classic networking.
I chose this example because recently IÕve helped a number of Macintosh developers who are writing such drivers. These people broke the rules and everything seemed to work fine. Unfortunately, Open Transport significantly changed the way AppleTalk is implemented, and the authors suddenly discovered the penalty of breaking the rules: unpredictable system deadlocks.
When the Finder copies a file, it makes a sequence of chained ioCompletion routines (see ÒAsynchronous Routines on the Macintosh,Ó develop 13) that reads chunks of data from the source volume and writes them to the destination volume. The Finder actually makes File Manager calls but, in cases like this, the File Manager effectively passes these calls st ®raight through to the appropriate block device driver.
The next two sections show how your block device driver can deadlock the system by not following these rules.
An Example of Breaking Rule #1
Imagine that your device driver breaks Rule #1, i.e., it calls another device driver synchronously. The following is a step-by-step description of how this leads to system deadlock:
1. The Finder calls PBReadAsync to read a chunk of the file from the local hard disk. This invokes the File Manager, which invokes the device driver, which invokes the SCSI Manager, which invokes the SCSI hardware.
2. The SCSI operation completes. The SCSI hardware interrupts the CPU to inform it of this. The interrupt service routine calls the ioCompletion for the SCSI device driver, which calls the ioCompletion routine for the File Manager, which calls the ioCompletion for the Finder. Because of the nature of the interrupt service routine, interrupts ar †e still disabled at this point.
3. The FinderÕs ioCompletion routine calls PBWriteAsync to write the data to the volume mounted on you block device driver. This invokes the File Manager, which invokes your device driver.
4. Your device driver calls the AppleTalk device driver synchronously. This is Request A. Unfortunately, the AppleTalk device driver is busy fielding another request (Request B) from a completely independent process, and queues your request waiting for Request B to complete. Your code sits inside the Device ManagerÕs vSyncWait loop, waiting for the Request B to complete.
5. The prior networking operation (Request B) completes. The networking hardware attempts to interrupt the CPU to let it know that Request B has completed. Unfortunately the CPU is sitting inside vSyncWait with interrupts disabled Ñ they were disabled by the SCSI hardware when it interrupted the CPU in step 2 Ñ and doesnÕt notice the interrupt from the networking hardware. The system is d ›eadlocked.
The basic problem here is that traditional Mac OS device drivers are single threaded, i.e., they can only handle a single request at a time. If you make a second request and the driver is busy and you donÕt give the driver the ability to complete the request, you deadlock.
An Example of Breaking Rule #2
Imagine that your device driver breaks Rule #2, i.e., it tests whether itÕs being called synchronously or asynchronously, and behaves differently in each case. The following is a step-by-step description of how this leads to system deadlock:
1. The Finder calls PBWriteAsync to write a chunk of data to your block device driver (Request A). You recognise this request is asynchronous (by testing ioTrap in the ParamBlock), send it to AppleTalk asynchronously, and then return to the Finder.
2. Another process calls PBWriteSync to write some data to your driver (Request B). Because your driver is currently busy, this request gets queued in your driverÕs queue.
3. The AppleTalk driver ca ’lls your ioCompletion routine to signify that your request is done. In response to this you call jIODone. jIODone completes Request A (and calls the FinderÕs ioCompletion routine) and then checks your driverÕs queue for any more pending requests. It notices that Request B is pending, and it calls your device driverÕs Prime to start that Request B. Remember that you are still running at interrupt time.
4. Your device driver is called to start Request B. It tests ioTrap, notices that the Request B is synchronous, and so calls AppleTalk synchronously. At this point your driver is calling a device driver synchronously at interrupt time, and you can deadlock the system as described in the previous section.
The basic problem here is that the ioTrap word in a ParamBlock only denotes whether the request was made synchronously, not whether the request is being executed at non-interrupt time.
Avoiding Deadlock
The only good way to avoid the proble óms described in the previous section is to issue any device driver calls you make inside your device driver asynchronously.
A traditional Mac OS device driver (DRVR A) that calls another driver (DRVR B) should operate in the following fashion:
1. Accept a request (Request A).
2. Ignore whether the request is synchronous or asynchronous.
3. Asynchronously issue the sub-request (Request B1) to DRVR B.
4. Return to the caller.
The sub-request should have an ioCompletion routine. The code for that ioCompletion routine should do the following:
1. If this is the last operation we need to do to fulfil Request A, jump to jIODone.
2. Otherwise, asynchronously issue another sub-request (Request Bn) to DRVR B with the same ioCompletion routine, and then return to the caller.
Structuring your device driver in this fashion turns your device driver into a state machine. If, for example, you have to issue two sub-requests for each request you receive, your device driver ends up with two states: Request B1 , and Request B2. Your completion routine would go:
1. Copy the data from the completed sub-request into the main requestÕs result buffer.
2. If the state is Request B2, complete the initial request by jumping to jIODone.
3. Otherwise, increment the state, issue the next request asynchronously, and return to the caller.
This structure works regardless of whether your driver (DRVR A) is called synchronously or asynchronously, and regardless of whether the driver you are calling (DRVR B) is synchronous or asynchronous.
Figures 1, 2, 3 and 4 illustrate these four cases.
Figure 1 A driver called synchronously, calling a synchronous driver.
Figure 2 A driver called asynchronously, calling a synchronous driver.
Figure 3 A driver called synchronously, calling an asynchronous driver.
Figure 4 A driver called asynchronously, calling an asynchronous driver
You might think to simplify your life by detecting whether you are being called synchronously or asynchro ónously, and changing your operation in each case. While it sounds like a neat idea in theory, it is a very bad idea in practice, for two reasons:
1. You have to handle the asynchronous case properly anyway, and if you handle the asynchronous case properly, the synchronous case just works. ThereÕs no point in writing twice as much code when half as much would do.
2. You will break Rule #2 and leave yourself open to deadlocks.
Exceptions That Prove the Rule
The expression ÒThe Exception Proves the RuleÓ actually means that the exception tests the rule. For Rules #1 and #2, there are two significant exceptions that we must explore in order to understand this topic fully.
Drivers That ArenÕt Called Asynchronously: Exception #1
Many people use traditional Mac OS device drivers for things that donÕt fit the model. The obvious example here are desk accessories, but older programs often use device drivers as a shared library mechanism. Drivers used in this way are not really part of the I/O system, an d generally arenÕt called asynchronously. This is the reason for the ÒIf you can be called asynchronouslyÓ clause in the rules.
Note that using device drivers as a shared library mechanism is now strongly discouraged. The Macintosh has a number of real shared library mechanisms that should meet your needs.
Note: If you use a DRVR as a pseudo shared library, you should have your client issue immediate calls to your driver (e.g., PBControlImmed). These calls are sent through to your driver directly, and are not queued in any way.
Classic SCSI Manager: Exception #2
One case that seems to contradict Rule #1 is the relationship between the File Manager and ÒclassicÓ SCSI device drivers. The ÒclassicÓ epithet refers to SCSI device drivers that were written prior to SCSI Manager ë 4.3. These drivers were necessarily synchronous because the SCSI Manager did not support asynchronous operations.
So how is it possible to call the File Manager, which in turn calls the device driver, which calls the SCSI Manager, at interrupt time, even though the SCSI Manager is necessarily synchronous?
The answer is simple: the File Manager contains specific code to support this. When you issue an asynchronous request, the File Manager checks whether the SCSI hardware is already in use. If it is, the File Manager defers the operation of the command until the SCSI hardware is free again. This gets around the potential deadlock, but it contradicts the spirit of Rule #1.
Note that the File Manager is only able to defer the request beca Àuse the request is asynchronous. If you called to File Manager synchronously, you would deadlock.
Summary
Most Macintosh programmers want to play by the rules. Unfortunately, in the case of traditional Mac OS device drivers, the rules are poorly documented and sometimes hard to understand. This Technote explains two important rules for traditional Mac OS device drivers. If you follow them, you will make the system as a whole more reliable.
Further Reference
n Asynchronous Routines on the Macintosh, develop 13, by Jim Luther
n Modern Operating Systems, by Andrew S. Tanenbaum, Prentice-Hall, 1992, ISBN 0-13-588187-0
Acknowledgments
Thanks to Brian Bechtel, Jim Luther, and Paul Freeburn.
Z ÿÿ N ° DSET : ÿÿ . H e /o ÿÿÿÿÿÿ≈t ° √ ÇΔ Y Ø ° ÿÿ ë}ÿÿÜ| e Æ ≈uT
H3ÿÿØ3 ÁÌ ÁÌ ≈xt
É3ÿÿû3 BÌ äÌ ≈uπ
‚ W3ÿÿö3 ‹Ì ßÌ ≈sä
6 ÿÿ * ÇΔ Y
' d ≠ ‘ ¡ €
hq " „ Ï ˘ Ö ˆ ‹ ˆ ‹ „ ‹ ˜ Ö ˘ Ï ˆ ‹¡ ¶ •
" ‰ ‹ ## #ù# #‡≥
£ ¡ ¡ € ¡ ¶ • • " Δ ‰ #<# £
h" Δ ‰ #< ¡ Ÿ ‘ ¡ € q " E Û K ä H Û H Û E Û H ä K Û H Û¡ ¶ •
" E Ü ## #ø# # ‡≥
£ ¡ ¡ € ¡ ¶ À • " H ‰ #H # £
h" H ‰ #H ¡ Ÿ ‘ ¡ € q " – s ¶ y – v – v – y ¶ v – s – v¡ ¶ •
" ® y #‡# #‡ø# # ≥
£ ¡ ¡ € ¡ ¶ À • " f v # H# £
h" f v # H ¡ Ÿ ‘¡ ˆ , Helvetica
. +‰yDevice Manager
* Request )$A
( — ‰ Issue Sync
˙ ˜ Ÿ ‘¡ ˆ ( = ¬Stack
˙ ˜ Ÿ ‘¡ ˆ ÿœ ÿœ
( kT
hΔ Δ d m Δ d m Δ d m • • fl •
)ime
hΔ ™ d Δ m ™ d Δ m ™ d Δ m * * >p ˙ ˜ Ÿ ‘¡ ˆ ( ÜDR)
ÿÿÿÿ =0 . / $ ÿÿÿÿ >0 . / ' ÿÿÿÿ ! ?0 . 4 , ÿÿÿÿ " @0 . 4 " ÿÿÿÿ % # B‹ ÿÿÿÿ ÿÿ $ C0 B B - ÿÿ % F0 B B " ÿÿ & K0 B B " ÿÿÿÿ ' M0 B F , ÿÿ ( N0 B F " ÿÿ ) O0 B F "
ÿÿ * P0 B F " ÿÿ + Q0 B F " ÿÿ , R0 B F "
ÿÿÿÿ - S0 B C . ÿÿÿÿ . T0 B C / ÿÿÿÿ / U0 B K 0 ÿÿ " 0 V0 B K " ÿÿÿÿ % 1 W‹ ÿÿÿÿ ÿÿ 2 X0 W W 1 ÿÿÿÿ 3 Y0 W W 2 ÿÿÿÿ 4 Z0 W W 2 ÿÿÿÿ 5 [0 W Y 3 ÿÿÿÿ 6 \0 W Y 4 ÿÿÿÿ 7 ]0 W Y 4
ÿÿÿÿ 8 ^0 W Y 4 ÿÿÿÿ 9 _0 W Y 4 ÿÿÿÿ : `0 W Y 4
ÿÿÿÿ ; a0 W X 5 ÿÿÿÿ < b0 W X 5 ÿÿÿÿ = c0 W Z 3 ÿÿÿÿ > d0 W Z 4 ÿÿÿÿ % ? e‹ ÿÿÿÿ ÿÿ @ f0 e e 6 ÿÿÿÿ A g0 e e " ÿÿÿÿ B h0 e e " ÿÿÿÿ C i0 e g 7
ÿÿÿÿ D j0 e g " ÿÿÿÿ E k0 e g " !
ÿÿÿÿ F m0 e g " "
ÿÿÿÿ G n0 e g " #
ÿÿÿÿ H o0 e g " $
ÿÿÿÿ I p0 e f : % ÿÿÿÿ J q0 e f : & ÿÿÿÿ K r0 e h , '
ÿÿÿÿ L s0 e h " ( ÿÿÿÿ % M t‹ ÿÿÿÿ ) ÿÿ N u0 t t ; * ÿÿÿÿ O v0 t t " + ÿÿÿÿ P w0 t t " , ÿÿÿÿ Q x0 t v , - ÿÿÿÿ R y0 t v " . ÿÿÿÿ S z0 t v " / ÿÿÿÿ T {0 t v " 0 ÿÿÿÿ U |0 t v " 1 ÿÿÿÿ V }0 t v " 2 ÿÿÿÿ W ~0 t u < 7 ÿÿÿÿ X 0 t u < 8 ÿÿÿÿ Y •0 t w 0 5 ÿÿÿÿ Z ™0 t w " 6 ÿÿÿÿ [ ≠‹ ÿÿÿÿ ) ÿÿ \ ∞0 ≠ ≠ , *
ÿÿ ö 8 Xÿÿÿÿ “ ÿÿ _ÿÿÿÿ ´ ÿÿ N `ÿÿÿÿ µ ÿÿ `ÿÿÿÿ ¶ ÿÿ aÿÿÿÿ · ÿÿ N bÿÿÿÿ ¸ ÿÿ H bÿÿÿÿ ’ ÿÿ cÿÿ – º ÿÿ .ÿÿÿÿ » ÿÿ dÿÿÿÿ π" ÿÿ P eÿÿÿÿ ∏% ÿÿ fÿÿÿÿ ≤& ÿÿ% gÿÿÿÿ ¿- ÿÿ hÿÿÿÿ À/ ÿÿ- M iÿÿÿÿ Á0 ÿÿ- iÿÿÿÿ Â ÿÿ ÿÿÿÿ Ã 0 ÿÿ H ÿÿÿÿ Ä ÿÿ ÿÿÿÿ Å % ÿÿ bÿÿÿÿ Æ G ÿÿ ÿÿÿÿ Ç » ÿÿ G P ÿÿÿÿ È ¬ ÿÿ +ÿÿÿÿ É 2 ÿÿ ß J .ÿÿÿÿ Ê Ä ÿÿ å H ÿÿÿÿ Ë D ÿÿ ù * Zÿÿÿÿ Ì l ÿÿ ö * Xÿÿÿÿ Í ÿÿ Í * Hÿÿÿÿ Î ' ÿÿ Í Hÿÿÿÿ Ï ) ÿÿ- I iÿÿÿÿ ‹ + ÿÿ ’ ÿÿÿÿ Ñ ¶ å & ÿÿÿÿ Ò Æ ÿÿ + ^ÿÿÿÿ Ó Ì ÿÿ ÿÿ Ô Ì% ÿÿÿÿ Õ ÿÿ Í Hÿÿÿÿ Ö Ì Í
ÿÿÿÿ ◊ ÿÿ ù .ÿÿÿÿ Ø , ÿÿ ÿÿ Á Ù ∏ ÿÿ , iÿÿÿÿ Ú π ÿÿ ì Q Vÿÿÿÿ Û ÿÿ ì I Vÿÿÿÿ Ü ÿÿ ì Vÿÿÿÿ † ‹ Ì ì ÿÿÿÿ fi Õ Ì ì 9 ÿÿÿÿ ß 3 ÿÿ ì U Vÿÿÿÿ à Ê ÿÿÿÿ á fi ÿÿ Ê L (ÿÿÿÿ â 5 ÿÿ Ê V (ÿÿÿÿ ã A ÿÿ Ê U (ÿÿÿÿ ä I ÿÿ Ê W (ÿÿ ä å ¸ ÿÿ Ê W (ÿÿÿÿ æ Ï ÿÿ Ê X (ÿÿÿÿ ç Î ÿÿ Í U .ÿÿ † è Ì Í ÿÿÿÿ é Ô Ö Y ÿÿÿÿ ê ◊ å Z ÿÿ ê ë L Z ÿÿ ë ì º Z ÿÿ é í H Y ÿÿ ì î ≤ G Z ÿÿÿÿ ï Â ÿÿ% U gÿÿÿÿ › Ø ÿÿ ù [ .ÿÿ fi ñ
Ì ù 9 ÿÿ î ò ü Z ÿÿ À ó ( ÿÿ , M iÿÿÿÿ ô E ÿÿ , iÿÿÿÿ õ ! $ ÿÿÿÿ ö ˙ ÿÿ ÿÿÿÿ ÷ · ÿÿ bÿÿ ´ ø Ç ÿÿ ˙ N `ÿÿÿÿ ù À ÿÿ -ÿÿ ÷ ú Á ÿÿ À bÿÿ · û Ü ÿÿ À N bÿÿÿÿ ü È ÿÿ /ÿÿ ò ‡ ¬ Z ÿÿÿÿ fl
RULR≈v\ ÿÿ ÿ ÿÿ í÷ bÿô N N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ i ≠ B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ \ ÿÿ ÿ ≠ B ÿÿ i ‚ B b•.*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ $ ÿÿ ÿ H ÿÿ ÿ ‚ B ÿÿ i ˚ B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÷ ? ÿÿ $ ÿÿ í÷ Rÿ≤ ≥ ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÿ ª B < ÿÿ $ ÿÿ ÿÿ ÿ ? ÿÿ $ ÿÿ H ÿÿ i÷  B d ÿÿ l ÿÿ Δ ÿÿ ÿ z B ÿÿ ´ ÿÿ Ø ÿÿ ü ÿÿ ÿÿ D ÿÿ h ÿÿ ÷ C ÿÿ
‘ ÿÿ ° ÿÿ ÿÿ $ ÿÿ ÿ ÿÿ H ÿÿ ‡ @ ÿÿ l ÿÿ ÷ H ÿÿ i÷ ª B < ÿÿ ÿ C ÿÿ ÿ @ ÿÿ i÷ Z B ÿÿ i z B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ Δ ÿÿ í÷ jÿ≤ ≥ !! ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÿ b B ÿÿ b B ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j =ÿÿÿÿ ÿ z B ÿÿ ´ ÿÿ Ø ÿÿ ü ÿÿ ÿÿ D ÿÿ h ÿÿ ÿÿ $ ÿÿ H ÿÿ l ÿÿ Δ ÿÿ ´ >ÿÿÿÿ i÷ j B ?ÿÿÿÿ J b•.*à ! §˝d jl iìÌiìÜjøj i›\j @ÿÿÿÿ i6 ª B < b•.*à ! §˝d jl iìÌiìÜjøj i›\j Bÿÿÿÿ é÷ b C V . j . } . Δ . £ . ¶ . Ê . † . › . . .* .= .P .c .v .… .ˇ .’,iÏØ ÿÿ i b B N .*à ! i≤p¥Sä gÚ° g¥lg¥|g¿˘g¿¬g¨üg¿¨ Cÿÿÿÿ ª B < b•.*à ! §˝d jl iìÌiìÜjøj i›\j Dÿÿÿÿ i÷ b G
Eÿÿÿÿ i  B d b•.*à ! §˝d jl iìÌiìÜjøj i›\j Fÿÿÿÿ  B d b•.*à ! §˝d jl iìÌiìÜjøj i›\j Lÿÿÿÿ í÷ bÿô N N . j . } . Δ . £ . ¶ . Ê . † . › . . .* .= .P .c .v .… .ˇ .’,iÏØ ÿÿ i b B b•.*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ b B b•.*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ i ˚ b•.*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÿ  B d ÿÿ ÿ Z B Nÿÿÿÿ ÿ b B ÿÿ ˚ b•.*à ! §˝d jl iìÌiìÜjøj i›\j Pÿÿÿÿ ÿ z B ÿÿ i z B b•.*à ! §˝d jl iìÌiìÜjøj i›\j Qÿÿÿÿ ÿ b C V . j . } . Δ . £ . ¶ . Ê . † . › . . .* .= .P .c .v .… .ˇ .’,iÏØ Rÿÿÿÿ ÿ b G
Sÿÿÿÿ z B b•.*à ! §˝d jl iìÌiìÜjøj i›\j Tÿÿÿÿ ÿ bÿô N N . j . } . Δ . £ . ¶ . Ê . † . › . . .* .= .P .c .v .… .ˇ .’,iÏØ ÿÿÿÿÿÿ ÿ j B ÿÿ y b B B b•.*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ b B B b•.*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ í bÿæ N N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÿ bÿæ N N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ i b B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ b B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ i z B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ z B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ i ˚ N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ˚ N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ í Rÿ≤ ≥ ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÿ Rÿ≤ ≥ ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ í jÿ≤ ≥ !! ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÿ jÿ≤ ≥ !! ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ i b B ≥ .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ i j B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ j B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ y b B B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ b B B N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ í bÿô N N .*à ! §˝d jl iìÌiìÜjøj i›\j ÿÿ ÿ bÿô N N .*à ! §˝d jl iìÌiìÜjøj i›\j & Yÿÿ HASH‘≠ÉÕ H‘ëÉl GŸÉl ŒxËÕ MŒáËl I˘≠Ê V˘ûÉı U¢Ãl O ı K œ . Ö î>
ù *W=ù ' 7, 80 Q 9v :˝ ;À <0 , Q v ˝ À å
/ T y ı Ã , !Q #v %˝ ,À 1å 2
3 / 4 T 5 y 6
0 ≠ÈÁ Z ≠È÷ / ëÈX Y ëÈ⁄ cCRK A ÿ ?ÿ Cÿ (G÷
Hÿ K÷ P÷ &xÊÁ ^Æ áÊX ]ÿ "ΔÉ' XΔÉ5 i}È: W}ÈH h}É- ≤ ≠É gûÈ… f …ÂÁ e óÂX d ÂX + ÂX !˚ÂÁ \"ÂX ["#ÂX %¶Ü5 `&£ÛH _&£Ü- -Îä5 b.»ãH a.»ä- -P ÿ )P‡ $e Jeoù r1 à 2 LKUP fl Û ‡ ñ Ô Õ Ö Â ò Ä Ü „ è
° ± ” “ ´ µ ¶ · ¸ ’ º »!# π$' ∏ ≤()*+,. ¿ÿÿ À Á Ü ÿÿ $ NAME Default
Default SS Header Body Footer Footnote Footnote Index Heading2.H2 HeadingH2.H2 Code.CV Heading1.H1 #Italic $ HeadingH3.H3 &Bullet * Checklist -Number .Classic B Blue Gray 1 W Blue Gray 2 eColorful t
